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REMARKS 

Various claims were objected to because of certain informalities. The 
above amendments obviate the objections by utilizing consistent terminology and 
do not serve to narrow the claims. The amendments are solely in response to 
the objections raised by the Examiner and do not raise new issues that would 
prevent consideration of this response. 

The pending claims were rejected under 35 USC 1 03(a). Applicant 
respectfully traverses the rejection. 

By way of example, claim 1 relates to an apparatus for programming an 
implantable medical device (IMD). With that apparatus a clinician uses a 
programmer (A) to create a request to modify the IMD. That request is sent from 
the programmer (A) to the server (B). A monitor (C) receives the request from 
the server (A), and the monitor (C) then transmits that request to the IMD. Thus, 
the clinician uses A, to communicate with B, B communicates with C and C 
communicates with the IMD. A and C are not the same element. 

Snell lacks the claimed monitor, among other things. Applicant must 
respectfully assert that the Examiner's dismissal of this fact based on whether tt a 
difference in name" is distinguishing Is entirely unsupportable. The Snell system 
alone does not anticipate the claims, nor render them obvious either alone or 
combined with the references of record. 

In Snell, the clinician interfaces exclusively with the network programmer 
104 and the network programmer 104 is the exclusive component that 
communicates with the IMD 105; thus, it is proximate the patient with the IMD. 
The network server 102 is only used to provide more computing power to the 
network programmer 104. Thus, whether software is updated via this 
arrangement (Col. 5, lines 29-34) or "generates" the programming commands 
(Col. 5 lines 60 - Col. 6, lines 15) based upon what the clinician enters at the 
network programmer 104, the result Is the same. This is a system where the 
clinician has a device next to the patient and operates to effect programming 
changes at that location. 
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In order for the Examiner to construe Snell to teach the claimed apparatus 
(forgoing a consideration of Brown, for the moment) the clinician must use the 
network programmer (A) to create and communicate a request to the network 
server (B), the network server (B), sends this request back to the veiy same 
network programmer (A) which now is considered a different element or monitor 
(C) and the network programmer (A)/monrtor (C) communicates with the IMD. Of 
course, in Snell there is no monitor (C) and the lack of this element is more than 
a "naming" issue. 

In Snell, where the network programmer 104 is capable of creating the 
request, as claimed, then the device is acting as a stand-alone programmer and 
only relying on the network server for software upgrades, database access, etc. 
Alternatively, Snell explicitly states that the physician communicate with the 
network programmer (Col. 5, line 67) and that everything generated by the 
network server (102) is subject to "physician control" (Col. 6, lines 2-3). Thus, 
the physician uses the network programmer 104 to control what is sent to the 
1MD. In order to do so, the commands generated by the server are sent to the 
physician at the network programmer. 

In other words, Snell does not contemplate, teach or allow for remote 
programming of the device. The physician's presence is explicitly required at the 
patient's site and at the network programmer's site. The Examiner is 
conveniently and inappropriately removing the fact that the physician uses the 
network programmer 104 to generate the request The reference must be 
considered as a whole and in its entirety. There is no basis for removing the 
physician from interfacing with the network programmer or adding another 
interface at a different site and reclassifying the network programmer from what 
Snell teaches to the claimed monitor. Furthermore, Snell explicitly teaches away 
from this by indicating that the physician maintains control and must approve 
what is passed to the implantable medical device (CoL 6, lines 2-4). 



PAGE 11/14 * RCVD AT 6/18(2004 2:06:36 PM [Eastern Daylight Time] * SVR:USPT0-EFXRF-1/2 * DN1S:87293Q6 * C SiD : 7635 1 46982 * DURATION (mm-ss):03-34 



JUN.18.2004 1:08PM 7635146982 MEDTRONIC NO. 0773 P. 12 

Serial No. 10/072,782 
Applicants: Webbetal. 
Page 10 

Despite this, the Examiner has attempted to combine Snell with Brown. 
Brown teaches providing software updates to external glucose monitors. The 
Examiner's rejection asserts that there is no "programmer through which the 
physician creates the request" taught in Snell. Applicant is somewhat surprised 
to learn that Snell fails to provide a means by which the physician can create a 
request since the entirety of the Snell reference is directed to w a distributed 
system of network programmers" which by necessity require such input. 

Of course, network programmer 104 is where the physician creates the 
request. In most embodiments of Snell, the network programmer 104 is a 
complete standalone programmer and when not relying on the server for 
processing capability, there is still no "monitor" in the reference. Rather, the 
network programmer 104 has been renamed as a "monitor" solely for purposes 
of this rejection. Specifically, the Examiner asserts "Snell teaches the physician 
sending the request through the server 102 to the monitor 104, but lacks a 
programmer through which the physician creates the request." This overlooks 
the fact that the network programmer 104 (now named the monitor) is the 
physician interface and the information generated by the server is sent back to 
this exact same device. Applicant respectfully asserts that Snell lacks a monitor 
as claimed and lacks the claimed interrelation between the elements; a 
programmer is in fact provided and it accessed by the physician. The 
programmer is either network programmer 104 acting as a stand-alone 
programmer or network programmer 104 using server 102 for computational 
purposes. In no case is there a lack of a programming interface as purported by 
the Examiner. 

Next the Examiner explains that Brown teaches a "programmer 62." Of 
course, this is not a programmer for an Implantable medical device as presently 
claimed or as used in Snell, but merely a personal computer by which a doctor is 
able to send messages to a patient. In addition, the Examiner relies on Brown to 
teach "authorization codes." 



PAGE 12/14 * RCVD AT 6/18/2004 2:06:36 PM [Eastern Daylight Time] 1 SVR:USPT0-EFXRF-1/2 1 DNIS:8729306 • CSID: 7635 1 46982 * DURATION (mm-ss):0M4 



JUN. 18. 2004 1:08PM 7635146982 MEDTRONIC NO. 0773 P. 13 

Serial No. 10/072,782 
Applicants: Webbetal. 
Page 1 1 

Thus, the Examiner's rejection proposes to modify Snell by adding the 
Brown "programmer" because Snell "teaches a system in which a server is 
capable of receiving a request from a clinician and Brown '563 describes an 
appropriate system for transmitting such a request." In addition, the "combination 
would additionally maintain appropriate safety levels. 0 This is purportedly the 
statutorily required motivation to combine references. Applicant respectfully 
traverses. 

First, Snell does not lack the ability to transmit such a request; rather such 
a system is explicitly provided in context. Second, the ability to make a 
combination is not a motivation to do so. Third, a computer messaging system 
utilizing a physician's PC does not teach a programmer capable of interfacing 
with and programming an implantable medical device. Fourth, safety (in the 
authorization sense) is not at issue as the physician is controlling the network 
programmer in proximity to the patient as explicitly required by Snell. Any 
security protocols present exist at the network programmer. Fifth, the Examiner 
has proposed a modification with the motivation being a means to address a 
problem created solely by the modification. The Examiner is making the 
combination to craft a rejection based on the absence of a "programmer" in Snell. 
The Examiner has failed to indicate why such a modification would be motivated; 
rather, has explained that if made, Browns authentication would be useful to the 
modified system. 
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The present claims are directed to systems and methods that facilitate 
remote programming on an implantable medical device. Snell does not teach the 
claimed elements. Brown is wholly irrelevant, as it does not address 
programming of implantable medical devices. The combination of these 
reference is inappropriate and unsupportable and even if made, does not teach 
the claimed invention. For these and other reasons, the rejections must be 
withdrawn. 



Respectfully submitted, 
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